Adaptive baud rate in light-based communication

ABSTRACT

Light-based communication (LCom) techniques are disclosed for adaptively adjusting the baud rate of a luminaire to optimize the LCom signal transmitted for an intended receiver device. The adaptive baud rate can be adjusted by a process that includes, for example: determining decoding parameters of the receiver device, the device including a camera for receiving LCom signals, and a display. The process further includes calculating a baud rate suitable for the receiver device based on the decoding parameters, and causing the baud rate to be set at the luminaire. The process may further include at least one of: verifying the baud rate at the receiver device; adjusting the decoding parameters of the receiver device if baud rate cannot be adjusted to meet a current configuration of decoding parameters; and prompting a user to rotate receiver device to improve orientation of the luminaire with respect to a raster direction of the camera.

FIELD OF THE DISCLOSURE

The present disclosure relates to solid-state lighting (SSL) and moreparticularly to light-based communication via SSL.

BACKGROUND

Global positioning system (GPS) devices are commonly used to facilitatenavigation on Earth. These GPS devices are designed to communicate withorbiting satellites that transmit location and time information. Closerto the Earth's surface, such satellite-based navigation can besupplemented using local area wireless technologies, such as Wi-Fi,which utilize radio frequency (RF) signals to communicate with nearbycompatible devices. These types of wireless technologies typicallyemploy wireless access points (Wi-Fi hotspots) to establish networkaccess, and in cases of secured wireless networks, a password or othersecurity credentials normally must be provided in order to gain networkaccess.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example light-basedcommunication (LCom) system configured in accordance with an embodimentof the present disclosure.

FIG. 2A is a block diagram illustrating an LCom-enabled luminaireconfigured in accordance with an embodiment of the present disclosure.

FIG. 2B is a block diagram illustrating an LCom-enabled luminaireconfigured in accordance with another embodiment of the presentdisclosure.

FIG. 3 illustrates an example arbitrary LCom signal as may betransmitted by an LCom-enabled luminaire, in accordance with anembodiment of the present disclosure.

FIG. 4 illustrates an example computing device configured in accordancewith an embodiment of the present disclosure.

FIG. 5A illustrates an example LCom system, including an LCom-enabledluminaire and a computing device, in accordance with an embodiment ofthe present disclosure.

FIG. 5B illustrates an example method for emitting position informationfrom an LCom-enabled luminaire, in accordance with an embodiment of thepresent disclosure.

FIG. 5C illustrates an example graphical map of LCom-enabled luminairesdeployed in a given venue, and corresponding LCom transmissionsindicating the location of that particular luminaire within the venue,in accordance with an embodiment of the present disclosure.

FIG. 5D illustrates an example scenario in which a computing device isconfigured to output instruction by way of visual feedback to a user, inaccordance with an embodiment of the present disclosure.

FIGS. 6A and 6B each illustrate example orientations between luminairesand a computing device, and how that affects the ability of the deviceraster lines to decode LCom messages from the luminaires.

FIG. 7 is a flow chart illustrating a method for setting a baud rate forLCom communication, in accordance with an embodiment of the presentdisclosure.

FIG. 8 illustrates measurement of the length of the luminaire in rasterlines which corresponds to the ability to resolve the luminaire's ID, inaccordance with an embodiment of the present disclosure.

FIG. 9 illustrates different baud rates, according to some embodimentsof the present disclosure.

These and other features of the present embodiments will be understoodbetter by reading the following detailed description, taken togetherwith the figures herein described. The accompanying drawings are notintended to be drawn to scale. In the drawings, each identical or nearlyidentical component that is illustrated in various figures may berepresented by a like numeral. For purposes of clarity, not everycomponent may be labeled in every drawing.

DETAILED DESCRIPTION

Light-based communication (LCom) generally refers to the communicationbetween a luminary and an optical receiver device, such as a smartphone,tablet, or other mobile computing device, using a pulsing light signalthat is encoded with data. In particular, the receiver device includes acamera or other imaging circuitry capable of sensing pulsing light fromthe luminary, and may further include one or more processors forprocessing the received light. The light utilized in LCom may be of anyspectral band, visible or otherwise, and may be of any intensity, asdesired for a given target application or end-use. With respect tovisible light, note that the pulsing is done at a relatively highfrequency (e.g., 1 KHz or higher), and is generally imperceptible to thehuman eye, so that light-based communication can co-exist with a givenillumination scheme. One application of LCom is indoor navigation, whichcan be used to supplement or otherwise enhance the precision andaccuracy over other technologies such as GPS and WiFi locationing. Forinstance, LCom could be used in retail setting to guide customers(empowered with a smartphone or other suitable mobile computing device)to products of interest on a given shelf within a given store. LCom forindoor navigation assumes that the light fixture itself knows itslocation. However, a non-trivial challenge associated with LCom iscreating an encoding/decoding schema that works across most if not allmobile computing devices. In particular, the baud rate of the luminairehas to be compatible with the given optical receiver device. To thisend, creating a universal or otherwise broadly applicableencoding/decoding schema is a challenge given the wide variety ofreceiver device platform configurations with respect to features such ascameras, operating systems, and processing power (consider, forinstance, the various smartphones available from manufacturers such asSamsung and Apple Inc). In short, any given mobile computing deviceshould work under the same set of luminaires.

Thus, and in accordance with an embodiment, techniques are disclosed foradaptively adjusting the baud rate of a given luminaire to optimize theLCom light signal transmitted for a given computing device (sometimesreferred to as a “receiver” device). The optimization can beaccomplished, for example, by providing decoding parameters of the givenreceiver device back to the luminaire through a wireless back channel,such as a Bluetooth or WiFi or other radio frequency channel, or even awired channel such as a USB port at the entrance of a given LCom-enabledfacility (where the receiver device could be plugged-in and queried forits decoding parameters). Decoding parameters may generally include anyinformation which allows the luminaire to identify a baud rate at whichit can transmit LCom signals that will be decodable by the intendedreceiver device. Such decoding parameters may be, for example, a makeand model of the receiver device (such that the decoding capabilitiescan then be looked up or otherwise inferred based on that information),or more specific information such as processing speed, camera/sensortypes, number of raster lines, screen resolution, and other informationthat can be used to determine a suitable baud rate. In any such cases,based on the receiver device's configuration (e.g., type of hardware,decoding ability), and possibly other factors such as receiver deviceorientation and environment, that receiver device can request adifferent baud rate to increase the accuracy/reliability of the LCommessaging. The baud rate can be provided to the luminaire in real timeor computed by the luminaire in real time. Thus, the baud rate of agiven luminaire can be dynamic and controllable on-the-fly and cantherefore be adapted to any receiver device. Note that the adapting maynot only enable an LCom-based communication channel to be created, butcan also be used to improve an already existing LCom-based communicationchannel by, for example, reducing delay times and increasingreliability.

One application where the techniques provided herein can be used is forLCom-based indoor navigation, which relies on luminaires transmittingtheir location to a user mobile computing device (e.g., smartphone,tablet, or other mobile computing device capable of receiving aprocessing LCom signals). Existing smartphones, tablets, and other suchmobile computing devices typically utilize a combination of globalpositioning system (GPS) and Wi-Fi technologies to provide navigationcapabilities, such as various Wi-Fi positioning systems (WPS). However,these existing GPS-based and Wi-Fi-based techniques are not particularlywell-suited for indoor navigation. In particular, GPS has an accuracy ofonly several meters, and the availability and range of Wi-Fi networkconnections are limited by factors such as the placement of Wi-Fihotspots, security restrictions imposed by network providers, and otherenvironmental factors. Thus, the combination of GPS and Wi-Fi can failto achieve sufficiently refined accuracies for purposes of indoornavigation. As will be appreciated, the LCom techniques provided hereincan be used to supplement such navigation systems, but the techniquesmay also be used on their own. Any number of other applications may alsobenefit from the adaptive baud rate techniques.

As will be further appreciated in light of this disclosure, baud ratefor LCom is similar to baud rate for electronic communication. Thedefinition of baud rate is a number related to the speed of datatransmission in a given communication system. The rate generallyindicates the number of electrical oscillations (or other intentionaloscillations) per second that occurs within a data transmission. Thismeans that the higher the baud rate, the more bits per second that aretransferred.

A number of advantages associated with optimizing the baud rate for LComwill be apparent in light of this disclosure. For instance, in someembodiments, the techniques provided herein can be used to adapt thebaud rate of given luminaire to accommodate different decoding hardware(with respect to past, present, and future receiver devices). In somecases, the techniques can be used to compensate for orientation andposition of the receiver device relative to the luminaire, and toguarantee that LCom data is transmitted within one frame (frame capturedby camera of receiver device, such as a smartphone camera). Thetechniques may also be used to optimize LCom transmission in terms ofdelay times and reliability, even for an established LCom communicationlink. In still further embodiments, the techniques can be used to adaptto LCom-enabled luminaires made by different manufacturers. In otherwords, the luminaires could match the baud rate of other luminaires forinteroperability, which is particularly helpful when there are currentlyno broadly adopted standards for defining LCom communications.

System Architecture

FIG. 1 is a block diagram illustrating an example light-basedcommunication (LCom) system 10 configured in accordance with anembodiment of the present disclosure. As can be seen, system 10 mayinclude one or more LCom-enabled luminaires 100 configured forlight-based communicative coupling with a receiver computing device 200via LCom signal(s). As discussed herein, such LCom may be provided, inaccordance with some embodiments, via visible light-based signals. Insome cases, LCom may be provided in only one direction; for instance,LCom data may be passed from a given LCom-enabled luminaire 100 (e.g.,the transmitter) to a computing device 200 (e.g., the receiver), or froma computing device 200 (e.g., the transmitter) to a given LCom-enabledluminaire 100 (e.g., the receiver). In some other cases, LCom may beprovided in a bi-directional fashion between a given LCom-enabledluminaire 100 and a computing device 200, where both act as atransceiver device capable of transmitting and receiving.

In some cases in which system 10 includes a plurality of LCom-enabledluminaires 100, all (or some sub-set thereof) may be configured forcommunicative coupling with one another so as to provide inter-luminairecommunication. In one such scenario, for instance, the inter-luminairecommunication can be used to notify other luminaries 100 that a givencomputing device 200 is currently present, as well as the baud ratechosen for that particular device 100. Such inter-luminairecommunication is not needed, however, as will be appreciated in light ofthis disclosure.

As can be further seen in this example embodiment, system 10 allows forcommunicative coupling with a network 300 and one or more servers orother computer systems 301. Communicative coupling may be provided, forexample, between network 300 and computing device 200 and/or one or moreLCom-enabled luminaires 100, as desired. The network 300 may be a localarea wireless network, a local wired network, or a combination of localwired and wireless networks, and may further include access to a widearea network such as the Internet or a campus-wide network. In short,network 300 can be any communications network. As will be furtherappreciated herein, prior to establishing an LCom communication linkbetween a given device 200 and one or more of the luminaires 100, thenetwork 300 may be used by the device 200 to provide its decodingparameters to the luminaires 100 or computer system 300, so that asuitable baud rate can be identified and then adopted by the luminaires100 to initiate LCom communications. In still other embodiments, apre-computed baud rate suitable for the given device 200 can be providedto the luminaire 100 by the device 200 itself, or by a computer system301 via network 300 once the given device 200 has been identified bythat computer system 301.

The computer systems 301 may be any suitable computing system capable ofcommunicating over a network 300, such as a cloud-based server computer,and may be programmed or otherwise configured to provide an LCom relatedservice, according to some embodiments. For example, an LCom relatedservice might be that the computer system 301 is configured to providestorage of currently available receiver device decoding parametersindexed by device manufacture and model, for example. In that way, onlythe computing device make and model need be known and the decodingparameters could then be looked up and passed to the luminaires 100 sothat a suitable baud rate could be computed and adopted by theluminaires 100. In still other embodiments, a suitable baud rate can belooked up on the computer system 301, and that baud rate can then bepassed to the luminaries 100 to initiate LCom communication with thedevice 200. Numerous other such configurations will be apparent in lightof this disclosure.

FIG. 2A is a block diagram illustrating an LCom-enabled luminaire 100 aconfigured in accordance with an embodiment of the present disclosure.FIG. 2B is a block diagram illustrating an LCom-enabled luminaire 100 bconfigured in accordance with another embodiment of the presentdisclosure. As can be seen, a difference between luminaire 100 a andluminaire 100 b is with respect to the location of controller 150. Forconsistency and ease of understanding of the present disclosure,LCom-enabled luminaires 100 a and 100 b hereinafter may be collectivelyreferred to generally as an LCom-enabled luminaire 100, except whereseparately referenced. Further note that while various modules are shownas distinct modules for purposes of illustration, any number of themodules may be integrated with one or more other modules. For instance,the controller 150 may be integrated with the driver 120. Similarly, theprocessor(s) 140 and memory 130 may be integrated within the controller150. Numerous other configurations can be used.

As can be seen, a given LCom-enabled luminaire 100 may include one ormore solid-state light sources 110, in accordance with some embodiments.The quantity, density, and arrangement of solid-state light sources 110utilized in a given LCom-enabled luminaire 100 may be customized, asdesired for a given target application or end-use. A given solid-statelight source 110 may include one or more solid-state emitters, which maybe any of a wide range of semiconductor light source devices, such as,for example, a light-emitting diode (LED), an organic light-emittingdiode (OLED), a polymer light-emitting diode (PLED), or a combination ofany of these. A given solid-state emitter may be configured to emitelectromagnetic radiation, for example, from the visible spectral bandand/or other portions of the electromagnetic spectrum not limited to theinfrared (IR) spectral band and/or the ultraviolet (UV) spectral band,as desired for a given target application or end-use. In someembodiments, a given solid-state emitter may be configured for emissionsof a single correlated color temperature (CCT) (e.g., a whitelight-emitting semiconductor light source). In other embodiments, agiven solid-state emitter may be configured for color-tunable emissions.For instance, in some cases, a given solid-state emitter may be amulti-color (e.g., bi-color, tri-color, etc.) semiconductor light sourceconfigured for a combination of emissions, such as: (1) red-green-blue(RGB); (2) red-green-blue-yellow (RGBY); (3) red-green-blue-white(RGBW); (4) dual-white; and/or (5) a combination of any one or morethereof. In some cases, a given solid-state emitter may be configured asa high-brightness light source. In some embodiments, a given solid-stateemitter may be provided with a combination of any one or more of theaforementioned example emissions capabilities. In any case, a givensolid-state emitter can be packaged or non-packaged, as desired, and insome cases may be populated on a printed circuit board (PCB) or othersuitable intermediate/substrate. In some cases, power and/or controlconnections for a given solid-state emitter may be routed from a givenPCB to a driver 120 (discussed in turn below) and/or otherdevices/componentry, as desired. Other suitable configurations for theone or more solid-state emitters of a given solid-state light source 110will depend on a given application and will be apparent in light of thisdisclosure.

A given solid-state light source 110 also may include one or more opticsoptically coupled with its one or more solid-state emitters. Inaccordance with some embodiments, the optic(s) of a given solid-statelight source 110 may be configured to transmit the one or morewavelengths of interest of the light (e.g., visible, UV, IR, etc.)emitted by solid-state emitter(s) optically coupled therewith. To thatend, the optic(s) may include an optical structure (e.g., a window,lens, dome, etc.) formed from any of a wide range of optical materials,such as, for example: (1) a polymer, such as poly(methyl methacrylate)(PMMA) or polycarbonate; (2) a ceramic, such as sapphire (Al₂O₃) oryttrium aluminum garnet (YAG); (3) a glass; and/or (4) a combination ofany one or more thereof. In some cases, the optic(s) of a givensolid-state light source 110 may be formed from a single (e.g.,monolithic) piece of optical material to provide a single, continuousoptical structure. In some other cases, the optic(s) of a givensolid-state light source 110 may be formed from multiple pieces ofoptical material to provide a multi-piece optical structure. In somecases, the optic(s) of a given solid-state light source 110 may includeoptical features, such as, for example: (1) an anti-reflective (AR)coating; (2) a reflector; (3) a diffuser; (4) a polarizer; (5) abrightness enhancer; (6) a phosphor material (e.g., which converts lightreceived thereby to light of a different wavelength); and/or (7) acombination of any one or more thereof. In some embodiments, theoptic(s) of a given solid-state light source 110 may be configured, forexample, to focus and/or collimate light transmitted therethrough. Othersuitable types, optical transmission characteristics, and configurationsfor the optic(s) of a given solid-state light source 110 will depend ona given application and will be apparent in light of this disclosure.

In accordance with some embodiments, the one or more solid-state lightsources 110 of a given LCom-enabled luminaire 100 may be electronicallycoupled with a driver 120. In some cases, driver 120 may be anelectronic driver (e.g., single-channel; multi-channel) configured, forexample, for use in controlling one or more solid-state emitters of agiven solid-state light source 110. For instance, in some embodiments,driver 120 may be configured to control the on/off state, dimming level,color of emissions, correlated color temperature (CCT), and/or colorsaturation of a given solid-state emitter (or grouping of emitters). Tosuch ends, driver 120 may utilize any of a wide range of drivingtechniques, including, for example: (1) a pulse-width modulation (PWM)dimming protocol; (2) a current dimming protocol; (3) a triode foralternating current (TRIAC) dimming protocol; (4) a constant currentreduction (CCR) dimming protocol; (5) a pulse-frequency modulation (PFM)dimming protocol; (6) a pulse-code modulation (PCM) dimming protocol;(7) a line voltage (mains) dimming protocol (e.g., dimmer is connectedbefore input of driver 120 to adjust AC voltage to driver 120); and/or(8) a combination of any one or more thereof. Other suitableconfigurations for driver 120 and lighting control/driving techniqueswill depend on a given application and will be apparent in light of thisdisclosure.

As will be appreciated in light of this disclosure, a given solid-statelight source 110 also may include or otherwise be operatively coupledwith other circuitry/componentry, for example, which may be used insolid-state lighting. For instance, a given solid-state light source 110(and/or host LCom-enabled luminaire 100) may be configured to host orotherwise be operatively coupled with any of a wide range of electroniccomponents, such as: (1) power conversion circuitry (e.g., electricalballast circuitry to convert an AC signal into a DC signal at a desiredcurrent and voltage to power a given solid-state light source 110); (2)constant current/voltage driver componentry; (3) transmitter and/orreceiver (e.g., transceiver) componentry; and/or (4) local processingcomponentry. When included, such componentry may be mounted, forexample, on one or more driver 120 boards, in accordance with someembodiments.

As can be further seen from FIGS. 2A-2B, a given LCom-enabled luminaire100 may include memory 130 and one or more processors 140. Memory 130can be of any suitable type (e.g., RAM and/or ROM, or other suitablememory) and size, and in some cases may be implemented with volatilememory, non-volatile memory, or a combination thereof. A given processor140 may be configured as typically done, and in some embodiments may beconfigured, for example, to perform operations associated with a givenhost LCom-enabled luminaire 100 and one or more of the applications 132thereof (e.g., within memory 130 or elsewhere). In some cases, memory130 may be configured to be utilized, for example, for processorworkspace (e.g., for one or more processors 140) and/or to store media,programs, applications, and/or content on a host LCom-enabled luminaire100 on a temporary or permanent basis. In one example embodiment, thememory 130 stores location information that indicates where theluminaire is deployed (for purposes of facilitating navigation, aspreviously explained), and may further include a look-up table (LUT) orother memory facility that indexes baud rates by computing device type.Table 1 shows an example look-up table according to one such embodiment.Assume that each of A through F represents a transmission baud ratewhich can be utilized by luminaires 100. Thus, in some cases, a givenprocessor 140 can identify the baud rate at which the luminary 100should transmit based on received decoding parameters (these parametersmay be provided network 300, for example, whether those parameters behigh level information such as make and model of the subject computingdevice 200 or lower level information about that device 200 such as itssensing capability (e.g., camera imaging speed and resolution).

TABLE 1 Baud Rates LUT Make (↓) Model (→) 5S 6S Galaxy S6 Galaxy S5 MotoX Moto G Apple Inc A B Samsung C D Motorola E F

The one or more applications 132 stored in memory 130 can be accessedand executed, for example, by the one or more processors 140 of a givenLCom-enabled luminaire 100. In accordance with some embodiments, a givenapplication or module 132 can be implemented in any suitable standardand/or custom/proprietary programming language, such as, for example:(1) C; (2) C++; (3) objective C; (4) JavaScript; and/or (5) any othersuitable custom or proprietary instruction sets. In a more generalsense, the applications or modules 132 can be instructions encoded onany suitable non-transitory machine-readable medium that, when executedby one or more processors 140, carries out functionality of a givenLCom-enabled luminaire 100, in part or in whole. In one exampleembodiment, at least one of these modules 132 is a routine fordetermining a baud rate for a given computing device 200, based ondecoding parameters received from that device 200. In still otherembodiments, the at least one module 132 receives the target baud ratefrom the computing device 200 or the network 300. In any case, the baudrate can be dynamically selected for a given computing device 200, andthe luminaire can then execute LCom communication using that baud rate.

In accordance with some embodiments, the one or more solid-state lightsources 110 of a given LCom-enabled luminaire 100 can be electronicallycontrolled, for example, to output light and/or light encoded with LComdata (e.g., an LCom signal). To that end, a given LCom-enabled luminaire100 may include or otherwise be communicatively coupled with one or morecontrollers 150. In some such example embodiments, such as thatillustrated in FIG. 2A, a controller 150 may be hosted by a givenLCom-enabled luminaire 100 and operatively coupled (e.g., via acommunication bus/interconnect) with the one or more solid-state lightsources 110 (1−N) of that LCom-enabled luminaire 100. In this examplecase, controller 150 may output a digital control signal to any one ormore of the solid-state light sources 110 and may do so, for example,based on wired and/or wireless input received from a given local source(e.g., such as on-board memory 130) and/or remote source (e.g., such asa control interface or network 300). As a result, a given LCom-enabledluminaire 100 may be controlled in such a manner as to output any numberof output beams (1−N), which may include light and/or LCom data (e.g.,an LCom signal), as desired for a given target application or end-use.However, the present disclosure is not so limited.

For example, in some other embodiments, such as that illustrated in FIG.2B, a controller 150 may be packaged or otherwise hosted, in part or inwhole, by a given solid-state light source 110 of a given LCom-enabledluminaire 100 and operatively coupled (e.g., via a communicationbus/interconnect) with the one or more solid-state light sources 110. IfLCom-enabled luminaire 100 includes a plurality of such solid-statelight sources 110 hosting their own controllers 150, then each suchcontroller 150 may be considered, in a sense, a mini-controller,providing LCom-enabled luminaire 100 with a distributed controller 150.In some embodiments, controller 150 may be populated, for example, onone or more PCBs of the host solid-state light source 110. In thisexample case, controller 150 may output a digital control signal to anassociated solid-state light source 110 of LCom-enabled luminaire 100and may do so, for example, based on wired and/or wireless inputreceived from a given local source (e.g., such as on-board memory 130)and/or remote source (e.g., such as a control interface, optionalnetwork 300, etc.). As a result, LCom-enabled luminaire 110 may becontrolled in such a manner as to output any number of output beams(1−N), which may include light and/or LCom data (e.g., an LCom signal),as desired for a given target application or end-use.

In accordance with some embodiments, a given controller 150 may host oneor more lighting control modules and can be programmed or otherwiseconfigured to output one or more control signals, for example, to adjustthe operation of the solid-state emitter(s) of a given solid-state lightsource 110 according to the desired baud rate. For example, in somecases, a given controller 150 may be configured to output a controlsignal to control whether the light beam of a given solid-state emitteris on/off. In some instances, a given controller 150 may be configuredto output a control signal to control the intensity/brightness (e.g.,dimming; brightening) of the light emitted by a given solid-stateemitter. In some cases, a given controller 150 may be configured tooutput a control signal to control the color (e.g., mixing; tuning) ofthe light emitted by a given solid-state emitter. Thus, if a givensolid-state light source 110 includes two or more solid-state emittersconfigured to emit light having different wavelengths, the controlsignal may be used to adjust the relative brightness of the differentsolid-state emitters in order to change the mixed color output by thatsolid-state light source 110. In some embodiments, controller 150 may beconfigured to output a control signal to encoder 172 (discussed below)to facilitate encoding of LCom data for transmission by a givenLCom-enabled luminaire 100. In some embodiments, controller 150 may beconfigured to output a control signal to modulator 174 (discussed below)to facilitate modulation of an LCom signal for transmission by a givenLCom-enabled luminaire 100. Other suitable configurations and controlsignal output for a given controller 150 of a given LCom-enabledluminaire 100 will depend on a given application and will be apparent inlight of this disclosure.

In accordance with some embodiments, a given LCom-enabled luminaire 100may include an encoder 172. In some embodiments, encoder 172 may beconfigured, for example, to encode LCom data in preparation fortransmission thereof by the host LCom-enabled luminaire 100. To thatend, encoder 172 may be provided with any suitable configuration, aswill be apparent in light of this disclosure.

In accordance with some embodiments, a given LCom-enabled luminaire 100may include a modulator 174. In some embodiments, modulator 174 may beconfigured, for example, to modulate an LCom signal in preparation fortransmission thereof by the host LCom-enabled luminaire 100. In someembodiments, modulator 174 may be a single-channel or multi-channelelectronic driver (e.g., driver 120) configured, for example, for use incontrolling the output of the one or more solid-state emitters of agiven solid-state light source 110. In some embodiments, modulator 174may be configured to control the on/off state, dimming level, color ofemissions, correlated color temperature (CCT), and/or color saturationof a given solid-state emitter (or grouping of emitters). To such ends,modulator 174 may utilize any of a wide range of driving techniques,including, for example: (1) a pulse-width modulation (PWM) dimmingprotocol; (2) a current dimming protocol; (3) a triode for alternatingcurrent (TRIAC) dimming protocol; (4) a constant current reduction (CCR)dimming protocol; (5) a pulse-frequency modulation (PFM) dimmingprotocol; (6) a pulse-code modulation (PCM) dimming protocol; (7) a linevoltage (mains) dimming protocol (e.g., dimmer is connected before inputof modulator 174 to adjust AC voltage to modulator 174); and/or (8) anyother suitable lighting control/driving technique, as will be apparentin light of this disclosure. Other suitable configurations andcontrol/driving techniques for modulator 174 will depend on a givenapplication and will be apparent in light of this disclosure.

In accordance with some embodiments, a given LCom-enabled luminaire 100may include a multiplier 176. Multiplier 176 may be configured astypically done, and in some example embodiments may be configured tocombine an input received from an upstream modulator 174 with an inputreceived from an ambient light sensor 165 (discussed below). In someinstances, multiplier 176 may be configured to increase and/or decreasethe amplitude of a signal passing therethrough, as desired. Othersuitable configurations for multiplier 176 will depend on a givenapplication and will be apparent in light of this disclosure. Inaccordance with some embodiments, a given LCom-enabled luminaire 100 mayinclude an adder 178. Adder 178 may be configured as typically done, andin some example embodiments may be configured to combine an inputreceived from an upstream multiplier 178 with a DC level input. In someinstances, adder 178 may be configured to increase and/or decrease theamplitude of a signal passing therethrough, as desired. Other suitableconfigurations for adder 178 will depend on a given application and willbe apparent in light of this disclosure.

In accordance with some embodiments, a given LCom-enabled luminaire 100may include a digital-to-analog converter (DAC) 180. DAC 180 may beconfigured as typically done, and in some example embodiments may beconfigured to convert a digital control signal into an analog controlsignal to be applied to a given solid-state light source 110 of the hostLCom-enabled luminaire 100 to output an LCom signal therefrom. Note thatDAC 180 may further be integrated into controller 150, in someembodiments. Other suitable configurations will be apparent in light ofthis disclosure.

In accordance with some embodiments, a given LCom-enabled luminaire 100may include one or more sensors 160. In some embodiments, a givenLCom-enabled luminaire 100 optionally may include an altimeter 161. Whenincluded, altimeter 161 may be configured as typically done, and in someexample embodiments may be configured to aid in determining the altitudeof a host LCom-enabled luminaire 100 with respect to a given fixed level(e.g., a floor, a wall, the ground, or other surface). In someembodiments, a given LCom-enabled luminaire 100 optionally may include ageomagnetic sensor 163. When included, geomagnetic sensor 163 may beconfigured as typically done, and in some example embodiments may beconfigured to determine the orientation and/or movement of a hostLCom-enabled luminaire 100 relative to a geomagnetic pole (e.g.,geomagnetic north) or other desired heading, which may be customized asdesired for a given target application or end-use. In some embodiments,a given LCom-enabled luminaire 100 optionally may include an ambientlight sensor 165. When included, ambient light sensor 165 may beconfigured as typically done, and in some example embodiments may beconfigured to detect and measure ambient light levels in the surroundingenvironment of the host LCom-enabled luminaire 100. In some cases,ambient light sensor 165 may be configured to output a signal, forexample, to a multiplier 176 of LCom-enabled luminaire 100. In someembodiments, a given LCom-enabled luminaire 100 optionally may include agyroscopic sensor 167. When included, gyroscopic sensor 167 may beconfigured as typically done, and in some example embodiments may beconfigured to determine the orientation (e.g., roll, pitch, and/or yaw)of the host LCom-enabled luminaire 100. In some embodiments, a givenLCom-enabled luminaire 100 optionally may include an accelerometer 169.When included, accelerometer 169 may be configured as typically done,and in some example embodiments may be configured to detect motion ofthe host LCom-enabled luminaire 100. In any case, a given sensor 160 ofa given host LCom-enabled luminaire 100 may include mechanical and/orsolid-state componentry, as desired for a given target application orend-use. Also, it should be noted that the present disclosure is not solimited only to these example optional sensors 160, as additional and/ordifferent sensors 160 may be provided as desired for a given targetapplication or end-use, in accordance with some other embodiments, or nosensors 160 may be provided, as the case may be. Numerous configurationswill be apparent in light of this disclosure.

In accordance with some embodiments, a given LCom-enabled luminaire 100may include a communication module 170, which may be configured forwired (e.g., Universal Serial Bus or USB, Ethernet, FireWire, etc.)and/or wireless (e.g., Wi-Fi, Bluetooth, etc.) communication, asdesired. In accordance with some embodiments, communication module 170may be configured to communicate locally and/or remotely utilizing anyof a wide range of wired and/or wireless communications protocols,including, for example: (1) a digital multiplexer (DMX) interfaceprotocol; (2) a Wi-Fi protocol; (3) a Bluetooth protocol; (4) a digitaladdressable lighting interface (DALI) protocol; (5) a ZigBee protocol;and/or (6) a combination of any one or more thereof. It should be noted,however, that the present disclosure is not so limited to only theseexample communications protocols, as in a more general sense, and inaccordance with some embodiments, any suitable communications protocol,wired and/or wireless, standard and/or custom/proprietary, may beutilized by communication module 170, as desired for a given targetapplication or end-use. In some instances, communication module 170 maybe configured to facilitate inter-luminaire communication betweenLCom-enabled luminaires 100. In addition or alternatively, communicationmodule 170 may be configured so as to allow for receipt of informationfrom network 300, such as decoding parameters associated with thecomputing device 200, or a pre-computed baud rate. As explained herein,the decoding parameters associated with the computing device 200 can beused by the luminaire to compute a baud rate suitable for that computingdevice 200. Whether the baud rate is computed in real time at theluminaire or received from somewhere else, the baud rate can then beused to generate the LCom signals emitted by that luminaire 100. Thecommunication module 170 may be configured to use any suitable wiredand/or wireless transmission technologies (e.g., radio frequency, or RF,transmission; infrared, or IR, light modulation; etc.), as desired for agiven target application or end-use. Other suitable configurations forcommunication module 170 will depend on a given application and will beapparent in light of this disclosure.

As previously noted, a given LCom-enabled luminaire 100 may beconfigured, in accordance with some embodiments, to output light and/orlight encoded with LCom data (e.g., an LCom signal). FIG. 3 illustratesan example arbitrary LCom signal as may be transmitted by anLCom-enabled luminaire 100, in accordance with an embodiment of thepresent disclosure. As can be seen here, LCom-enabled luminaire 100 maybe configured to transmit a given LCom signal at a given baud rate overa given time interval (t₁−t₀). In some cases, a given LCom-enabledluminaire 100 may be configured to repeatedly output its one or moreLCom signals. In any case, the baud rate may be customized, as desiredfor a given target application or end-use.

FIG. 4 illustrates an example computing device 200 configured inaccordance with an embodiment of the present disclosure. As discussedherein, computing device 200 may be configured, in accordance with someembodiments: (1) to detect the light pulses of an LCom signal emitted bya transmitting LCom-enabled luminaire 100; and (2) to decode the LComdata from a detected LCom signal. To these ends, computing device 200can be any of a wide range of computing platforms, mobile or otherwise.For example, in accordance with some embodiments, computing device 200can be, in part or in whole: (1) a laptop/notebook computer orsub-notebook computer; (2) a tablet or phablet computer; (3) a mobilephone or smartphone; (4) a personal digital assistant (PDA); (5) aportable media player (PMP); (6) a cellular handset; (7) a handheldgaming device; (8) a gaming platform; (9) a desktop computer; (10) atelevision set; (11) a wearable or otherwise body-borne computingdevice, such as a smartwatch, smart glasses, or smart headgear; and/or(12) a combination of any one or more thereof. Other suitableconfigurations for computing device 200 will depend on a givenapplication and will be apparent in light of this disclosure.

As can be further seen from FIG. 4, computing device 200 may includememory 210 and one or more processors 220. Memory 210 can be of anysuitable type (e.g., RAM and/or ROM, or other suitable memory) and size,and in some cases may be implemented with volatile memory, non-volatilememory, or a combination thereof. A given processor 220 of computingdevice 200 may be configured as typically done, and in some embodimentsmay be configured, for example, to perform operations associated withcomputing device 200 and one or more of the modules thereof (e.g.,within memory 210 or elsewhere). In some cases, memory 210 may beconfigured to be utilized, for example, for processor workspace (e.g.,for one or more processors 220) and/or to store media, programs,applications, and/or content on computing device 200 on a temporary orpermanent basis. The one or more modules stored in memory 210 (e.g.,such as OS 212, UI 214, and/or one or more applications 216) can beaccessed and executed, for example, by the one or more processors 220 ofcomputing device 200. Just as explained with respect to memory 130 ofthe luminaires 100, memory 210 of the device 200 may include informationthat can be used to compute or otherwise set baud rate, whether it bepre-computed baud rates themselves or decoding parameters can that canbe used to determine an appropriate baud rate. In some cases, memory 210includes an LUT or other memory facility that indexes baud rates bycomputing device type, as previously discussed with respect to Table 1.Alternatively, memory 210 may include one or more files that containdecoding parameters that can be recalled or otherwise interrogated toinform the baud rate computing process, as will be appreciated in lightof this disclosure.

OS 212 can be implemented with any suitable OS, mobile or otherwise,such as, for example: (1) Android OS from Google, Inc.; (2) iOS fromApple, Inc.; (3) BlackBerry OS from BlackBerry Ltd.; (4) Windows PhoneOS from Microsoft Corp; (5) Palm OS/Garnet OS from Palm, Inc.; (6) anopen source OS, such as Symbian OS; and/or (7) a combination of any oneor more thereof. As will be appreciated in light of this disclosure, OS212 may be configured, for example, to aid in processing LCom dataduring its flow through computing device 200. Other suitableconfigurations and capabilities for OS 212 will depend on a givenapplication and will be apparent in light of this disclosure. A userinterface (UI) module 214 is provided as commonly done, and generallyallows for user interaction with the device 200 (e.g., such as agraphical touched-based UI on various smartphones and tablets). Anynumber of user interface schemes can be used.

In accordance with some embodiments, memory 210 may have stored therein(or otherwise have access to) one or more applications 216. In someinstances, computing device 200 may be configured to receive input, forexample, via one or more applications 216 stored in memory 210 (e.g.,such as an indoor navigation application). In accordance with someembodiments, a given application or module 216 can be implemented in anysuitable standard and/or custom/proprietary programming language, suchas, for example: (1) C; (2) C++; (3) objective C; (4) JavaScript; and/or(5) any other suitable custom or proprietary instruction sets. In a moregeneral sense, the applications or modules 216 can be instructionsencoded on any suitable non-transitory machine-readable medium that,when executed by one or more processors 220, carries out functionalityof a given computing device 200, in part or in whole. In one exampleembodiment, at least one of these modules 216 is a routine programmed orotherwise configured to provide decoding parameters of computing device200 to luminaire 100, so that luminaire 100 can determine a baud ratesuitable for the device 200. In still other embodiments, the at leastone module 216 may be configured to compute the target baud rate itselfand provide that baud rate to the luminaire 100, either directly vianetwork 300 or indirectly via a computer system 301. In any case, thebaud rate can be dynamically selected for a given computing device 200,and the luminaire can then execute LCom communication with that device200 using that baud rate. The at least one module 216 may be furtherconfigured to receive LCom signals and decode those signals. Inaddition, at least one module 216 may be further configured to alsomonitor the luminaire for any changes (orientation, with respect tocomputing device 200), and to update the baud rate computationperiodically (and pass any changes along to the luminaire 100).Likewise, in some embodiments, the at least one module 216 may befurther configured to optionally try to adjust its own settings tooptimize decoding in effort to deal with situations where control byluminaire 100 is not available, for whatever reason.

As can be seen further from FIG. 4, computing device 200 may include adisplay 230, in accordance with some embodiments. Display 230 can be anyelectronic visual display or other device configured to display orotherwise generate an image (e.g., image, video, text, and/or otherdisplayable content) there at. In some instances, display 230 may beintegrated, in part or in whole, with computing device 200, whereas insome other instances, display 230 may be a stand-alone componentconfigured to communicate with computing device 200 using any suitablewired and/or wireless communications means. In some cases, display 230optionally may be a touchscreen display or other touch-sensitivedisplay. To that end, display 230 may utilize any of a wide range oftouch-sensing techniques, such as, for example: (1) resistivetouch-sensing; (2) capacitive touch-sensing; (3) surface acoustic wave(SAW) touch-sensing; (4) infrared (IR) touch-sensing; (5) opticalimaging touch-sensing; and/or (6) a combination of any one or morethereof. In a more general sense, and in accordance with someembodiments, an optionally touch-sensitive display 230 generally may beconfigured to detect or otherwise sense direct and/or proximate contactfrom a user's finger, stylus, or other suitable implement at a givenlocation of that display 230. In some cases, an optionallytouch-sensitive display 230 may be configured to translate such contactinto an electronic signal that can be processed by computing device 200(e.g., by the one or more processors 220 thereof) and manipulated orotherwise used to trigger a given GUI action. In some cases, atouch-sensitive display 230 may facilitate user interaction withcomputing device 200 via the GUI 214 presented by such display 230.Numerous suitable configurations for display 230 will be apparent inlight of this disclosure.

In accordance with some embodiments, computing device 200 may include acommunication module 240, which may be configured for wired (e.g.,Universal Serial Bus or USB, Ethernet, FireWire, etc.) and/or wireless(e.g., Wi-Fi, Bluetooth, etc.) communication using any suitable wiredand/or wireless transmission technologies (e.g., radio frequency, or RF,transmission; infrared, or IR, light modulation; etc.), as desired. Inaccordance with some embodiments, communication module 240 may beconfigured to communicate locally and/or remotely utilizing any of awide range of wired and/or wireless communications protocols, including,for example: (1) a digital multiplexer (DMX) interface protocol; (2) aWi-Fi protocol; (3) a Bluetooth protocol; (4) a digital addressablelighting interface (DALI) protocol; (5) a ZigBee protocol; (6) a nearfield communication (NFC) protocol; (7) a local area network (LAN)-basedcommunication protocol; (8) a cellular-based communication protocol; (9)an Internet-based communication protocol; (10) a satellite-basedcommunication protocol; and/or (11) a combination of any one or morethereof. It should be noted, however, that the present disclosure is notso limited to only these example communications protocols, as in a moregeneral sense, and in accordance with some embodiments, any suitablecommunications protocol, wired and/or wireless, standard and/orcustom/proprietary, may be utilized by communication module 240, asdesired for a given target application or end-use. In some instances,communication module 240 may be configured to communicate with one ormore LCom-enabled luminaires 100 via network 300. Numerous suitableconfigurations for communication module 240 will depend on a givenapplication and will be apparent in light of this disclosure.

Also, as can be seen from FIG. 4, computing device 200 may include oneor more image capture devices 250, such as a front-facing image capturedevice 252 and/or a rear-facing image capture device 254, in accordancewith some embodiments. For consistency and ease of understanding of thepresent disclosure, front-facing image capture device 252 andrear-facing image capture device 254 hereinafter may be collectivelyreferred to generally as an image capture device 250, except whereseparately referenced. A given image capture device 250 can be anydevice configured to capture digital images, such as a still camera(e.g., a camera configured to capture still photographs) or a videocamera (e.g., a camera configured to capture moving images comprising aplurality of frames). In some cases, a given image capture device 250may include typical components such as, for instance, an opticsassembly, an image sensor, and/or an image/video encoder, and may beintegrated, in part or in whole, with computing device 200. A givenimage capture device 250 can be configured to operate using light, forexample, in the visible spectrum and/or other portions of theelectromagnetic spectrum not limited to the infrared (IR) spectrum,ultraviolet (UV) spectrum, etc. In some instances, a given image capturedevice 250 may be configured to continuously acquire imaging data. Asdescribed herein, a given image capture device 250 of computing device200 may be configured, in accordance with some embodiments, to detectthe light and/or LCom signal output of a transmitting LCom-enabledluminaire 100. In some instances, a given image capture device 250 maybe, for example, a camera like one typically found in smartphones orother mobile computing devices. Numerous other suitable configurationsfor a given image capture device 250 (e.g., front-facing image capturedevice 252; rear-facing image capture device 254) of computing device200 will depend on a given application and will be apparent in light ofthis disclosure.

In accordance with some embodiments, computing device 200 may includeone or more sensors 260. In some embodiments, computing device 200optionally may include a geomagnetic sensor 263. When included,geomagnetic sensor 263 may be configured as typically done, and in someexample embodiments may be configured to determine the orientationand/or movement of a host computing device 200 relative to a geomagneticpole (e.g., geomagnetic north) or other desired heading, which may becustomized as desired for a given target application or end-use. In someembodiments, computing device 200 optionally may include an ambientlight sensor 265. When included, ambient light sensor 265 may beconfigured as typically done, and in some example embodiments may beconfigured to detect and measure ambient light levels in the surroundingenvironment of the host computing device 200. In some embodiments,computing device 200 optionally may include a gyroscopic sensor 267.When included, gyroscopic sensor 267 may be configured as typicallydone, and in some example embodiments may be configured to determine theorientation (e.g., roll, pitch, and/or yaw) of the host computing device200. In some embodiments, computing device 200 optionally may include anaccelerometer 269. When included, accelerometer 269 may be configured astypically done, and in some example embodiments may be configured todetect motion of the host computing device 200. In any case, a givensensor 260 of a given host computing device 200 may include mechanicaland/or solid-state componentry, as desired for a given targetapplication or end-use. Also, it should be noted that the presentdisclosure is not so limited only to these example optional sensors 260,as additional and/or different sensors 260 may be provided, as desiredfor a given target application or end-use, in accordance with some otherembodiments. Numerous sensor configurations for device 200 will beapparent in light of this disclosure.

In accordance with some embodiments, computing device 200 may include orotherwise be communicatively coupled with one or more controllers 270. Agiven controller 270 may be configured to output one or more controlsignals to control any one or more of the various components/modules ofcomputing device 200 and may do so, for example, based on wired and/orwireless input received from a given local source (e.g., such ason-board memory 210) and/or remote source (e.g., such as a controlinterface, optional network 300, etc.). In accordance with someembodiments, a given controller 270 may host one or more control modulesand can be programmed or otherwise configured to output one or morecontrol signals, for example, to adjust the operation of a given portionof computing device 200. For example, in some cases, a given controller270 may be configured to output a control signal to control operation ofa given image capture device 250, and/or to output a control signal tocontrol operation of one or more sensors 260. Numerous otherconfigurations and control signal output for a given controller 270 ofcomputing device 200 will depend on a given application and will beapparent in light of this disclosure.

As can be seen further from FIG. 4, computing device 200 may include anaudio output device 280, in accordance with some embodiments. Audiooutput device 280 can be, for example, a speaker or any other devicecapable of producing sound from an audio data signal, in accordance withsome embodiments. Audio output device 280 can be configured, forexample, to reproduce sounds local to and/or received by its hostcomputing device 200. In some instances, audio output device 280 may beintegrated, in part or in whole, with computing device 200, whereas insome other instances, audio output device 280 may be a stand-alonecomponent configured to communicate with computing device 200 using anysuitable wired and/or wireless communications means, as desired.Numerous other suitable types and configurations for audio output device280 will depend on a given application and will be apparent in light ofthis disclosure.

Network 300 can be any suitable public and/or private communicationsnetwork. For instance, in some cases, network 300 may be a private localarea network (LAN) operatively coupled to a wide area network (WAN),such as the Internet. In some cases, network 300 may include one or moresecond-generation (2G), third-generation (3G), and/or fourth-generation(4G) mobile communication technologies. In some cases, network 300 mayinclude a wireless local area network (WLAN) (e.g., Wi-Fi wireless datacommunication technologies). In some instances, network 300 may includeBluetooth wireless data communication technologies. In some cases,network 300 may include supporting infrastructure and/orfunctionalities, such as a server and a service provider (e.g., computersystem 301), but such features are not necessary to carry outcommunication via network 300. In some instances, computing device 200may be configured for communicative coupling, for example, with anetwork 300 and one or more LCom-enabled luminaires 100. In some cases,computing device 200 may be configured to receive data from network 300,for example, which serves to supplement LCom data received by computingdevice 200 from a given LCom-enabled luminaire 100. In some instances,computing device 200 may be configured to receive data (e.g., such asposition, ID, baud rate, and/or other data pertaining to a givenLCom-enabled luminaire 100) from network 300 that facilitates indoornavigation via one or more LCom-enabled luminaires 100. In some cases,network 300 may include or otherwise have access to one or more lookuptables of data that may be accessed by a computing device 200communicatively coupled therewith, for purposes of determining anappropriate baud rate, as variously provided herein. Numerousconfigurations for network 300 will be apparent in light of thisdisclosure.

As previously noted, there are a number of non-trivial challengesassociated with modulating data over light and transmitting it intospace for LCom. For example, to prevent or otherwise minimize visualartifacts and other perceivable changes in light output, it may bedesirable to have the LCom light source transmit at a sufficiently highspeed. However, effective detection of the modulated light by a givenreceiver device depends on whether that device has sufficient receptioncapabilities. Currently available smartphone cameras typically have amaximum frame rate of 30 frames/second (FPS) or 60 FPS, providing onlyvery limited low-speed reception capabilities. As such, there iscurrently no known way to effectively utilize existing smartphone camerahardware in obtaining data modulated over light without either: (1)making a change in the transmitted light output, which would beperceivable to the user and any bystanders; or (2) adding costly,specialized receiver hardware to the receiver device.

Thus, and in accordance with some embodiments, techniques are disclosedfor coding LCom data in a manner that allows for detection thereof viaan image capture device 250 such as, for example, a standard low-speedsmartphone camera having a frame rate of 30 FPS. In some cases, thedisclosed techniques can be used, for example, in encoding and decodingLCom data in a manner that: (1) prevents or otherwise minimizesperceivable flicker of the light output by a transmitting LCom-enabledluminaire 100; and/or (2) avoids or otherwise reduces a need foradditional, specialized receiver hardware at computing device 200. Insome cases, the disclosed techniques can be used, for example, toenhance the baud rate between a transmitting LCom-enabled luminaire 100and a receiving computing device 200. For instance, if image capturedevice 250 is a typical smartphone front-facing camera configured tocapture images at 30 FPS at VGA resolution (640×480 pixels), and if astandard RGB color profile is utilized, then each frame captured by thatimage capture device 250 is about 900 KB of image data (640 pixels×480pixels×3 colors). Thus, at a frame rate of 30 FPS, that image capturedevice 250 may capture about 27 MB of raw image data each second, inaccordance with an example embodiment. In other embodiments, theresolution of the image capture device 250 may be different (e.g.,1334×750 pixels, or other standard frame resolutions, including highdefinition resolutions).

FIG. 5A illustrates an example LCom system, including an LCom-enabledluminaire and a computing device, in accordance with an embodiment ofthe present disclosure. As can be seen, this example scenario includestwo luminaires 100 each communicating with a computing device 200, whichhappens to be a smartphone running an LCom-based navigation application.The navigation application can be, for instance, one of the applications216 stored in memory 210 and executed by processor(s) 220. As can befurther seen, the LCom signals being communicated include data 500,which generally includes position information, which may be used tonavigate. For instance, if the user is receiving light from a specificluminaire 100 that has a known location, then the navigation application‘knows’ where the user is and can continue to guide the user along thetargeted path.

The position information 500 transmitted by the luminaires 100 may comein any number of forms. For instance, in some embodiments, the luminairepositions may be communicated as a relative position (e.g., relative toanother luminaire 100, or some other object having a known position),and/or as an absolute position (e.g., x-y coordinates of a grid-basedmap). In still other embodiments, the luminaire positions may becommunicated as an environment ID, wherein the transmitted ID translatesto a specific location on a given map of the environment beingnavigated. In some such example cases, for instance, a luminaire mightuse dual tone multi frequency (DTMF) encoding, which means itcontinuously sends two unique frequencies.

FIG. 5C shows how an example DTMF-based ID system might work. As can beseen, a given environment 271 is the area being navigated and has anumber of LCom-enabled luminaires 101. The environment 271 may be, forexample, a super market or retail store, or a shopping mall, or aparking garage, or a large office space, to name a few examples. Theenvironment 271 is effectively divided into a grid of physicallocations, each location being associated with at least one luminaire100. As can be further seen, each luminaire 100 is associated with twounique frequencies that it can transmit on a regular basis. The twounique frequencies can thus be used to correlate that particularluminaire's location to a specific location within the environment. Forinstance, if the user is receiving light from luminaire #1 (whichtransmits 697 Hz and 1209 Hz in this example embodiment), then thenavigation application ‘knows’ that the user is in the North-West cornerof the environment 271; similarly, if the user is receiving light fromluminaire #12 (which transmits 941 Hz and 1477 Hz in this exampleembodiment), then the navigation application ‘knows’ that the user is inthe South-East corner of the environment; and so on. So, in one examplescenario, assuming that environment 271 is a store selling goods of somekind, each location can be associated with a specific product or rangeof products. Thus, a user can be led to a given product location by thenavigation application, according to some embodiments. Note that theentire frequency-based grid can be scaled to higher or lower frequenciesand still operate as described here to uniquely identify the location ofindividual luminaires 100.

FIG. 5B illustrates an example method for emitting position informationfrom an LCom-enabled luminaire, in accordance with an embodiment of thepresent disclosure. As can be seen, the method includes emitting 501, byat least one solid-state light source of a luminaire, a light output.The method further includes modulating 503 the light output to emit anLCom signal, the LCom signal comprising data that includes positioninformation indicating the physical location of the at least one lightsource. This position information may indicate that particularluminaire's location directly by virtue of relative or absolute positioninformation, or indirectly by virtue of an environment ID thattranslates to a specific location on a given map of the environmentbeing navigated, as previously explained. Numerous variations on usingluminaires having known locations within a given area to be navigatedwill be apparent in light of this disclosure.

FIG. 5D illustrates an example scenario in which a computing device 200receiving LCom signals from luminaries 100 and is configured to output anavigational instruction by way of visual feedback to a user, inaccordance with an embodiment of the present disclosure. Note how theactual luminaire 100 in the physical space being navigated is beingimaged by way of camera 252, and the resulting image of that luminaire100 is provided on the display 230 of the device 200. Based on receivingLCom signals from that luminaire 100 (which indicate the position ofthat luminaire 100), the navigation application continues to guide theuser with a visual cue (an arrow in this example case). As the userprogresses down the passageway, each subsequent luminaire 100 that issimilarly imaged and processed by the device 200 allows the navigationalguidance to continue, until the user arrives at the luminaire associatedwith the user's intended destination.

FIGS. 6A and 6B show a user holding the computing device 200 in twodifferent orientations. The computing device 200 in this example is asmartphone, but can be any other suitable computing device as well. Ascan be seen, the device 200 includes a front-facing image capture device252 that is currently imaging the above-luminaires 100, and theresulting image is shown on display 230. Two luminaires are beingimaged, as can be further seen. In FIG. 6A, the user is holding thecomputing device 200 where the luminaires 100 are perpendicular to theraster lines (and therefore parallel to the raster direction). For thiscase, the luminaires 100 being imaged spans the maximum number of rasterlines. Assume, for example, camera frame having 750 raster linesperpendicular to the raster direction. Thus, a luminaire imaged with thedevice 200 in that orientation will spans the maximum a relatively largenumber of raster lines (e.g., 350 raster lines or more). However, in theexample of FIG. 6B, the luminaires 100 are parallel to the raster lines(and therefore perpendicular to the raster direction). Consequently,each imaged luminaire 100 effectively spans only a fraction of theraster lines, or otherwise fewer raster lines relative to when thedevice 200 is in the opposite orientation shown in FIG. 6A. While insome cases the user can be directed to orient the device 100 to be morelike the orientation shown in FIG. 6A (to improve the ability of device200 to receive and process LCom messages from luminaires 100), otherembodiments can solve this rastering problem through a variable baudrate which has the advantage of not requiring any effort/manualintervention with the user of the device 200.

As previously mentioned, there are a multitude of different computingdevices on the market. Ideally, all such devices would be able to decodethe LCom signal. However, this may not be physically possible given allthe variations. For instance, phone ‘A’ might read raster lines at 1,000raster lines per 100 ms versus phone ‘B’ that might read 1,000 rasterlines per 10 ms. Therefore, the effective sampling frequency is 10 kHzand 100 kHz respectively. With respect to the transmission side, assumea DTMF encoding scheme for purposes of this example scenario, such thatone of the frequencies is 20 kHz, for instance. According to the Nyquistfrequency rule, Camera ‘A’ sampling at 10 kHz would not be high enoughto decode the transmitting frequency without a lot of aliasing. To solvethis problem, the transmitting LCom-enabled luminaire can utilize slowerfrequencies. Likewise, if the smartphone is rotated where only 20 rasterlines cover the luminaire (shown in FIG. 6B), then the sampling periodis greatly reduced. Thus, there are many reasons why the baud rate of anLCom transmitter may not be optimal for a given receiver device, suchas: faster or slower sampling rate of camera; poor orientation of rasterlines with respect to luminaire orientation; inability for camera toresolve multiple high frequency transmissions at the same time; and agiven LCom message is spanning multiple frames where piecing themulti-frame message back together is difficult and potentiallyunreliable.

Methodology

FIG. 7 is a flow chart illustrating a method for setting a baud rate forLCom communication, in accordance with an embodiment of the presentdisclosure. The method may be carried out, for example, by anapplication executing on the receiving device 200, such as one theapplications 216 stored in memory 210 and executable by one or moreprocessors 220. In other embodiments, some parts of the method may becarried out elsewhere, as such as at the luminaire 100 and/or at aremote computer system 300. In any such cases, a baud rate can beselected for a given receiving device 200, and that baud rate can thenbe used by the luminaire(s) 100 which that device 200 is imaging. Agiven system might include, for example, 1,000 luminaires in a storethat are all transmitting their ID's through LCom-based signaling. Atany one spot in the store, a user with a smartphone or other receiverdevice may only see one to three luminaires in one camera frame. As theuser moves, the number of luminaires and size varies in each cameraframe. According to an example embodiment of the present disclosure, thesmartphone is configured to set the baud rate of the transmittingluminaire in such a way that decoding the transmitted ID is reliable.

As can be seen, the method includes determining 701 the various decodingparameters of the mobile computing. The may be accomplished in variousways. For instance, most operating systems allow for hardware profilesof its various componentry, including cameras and other sensors, to berecalled or otherwise queried from a local storage of the device 200such that fixed decoding parameters of that componentry is known. Oneexample would be a navigation app running on iOS operating systemindicating that the hardware is an iPhone 6 with a 4 MP camera runningat a shutter speed of 1/60 second. Other fixed parameters include frameresolution and raster line timings such as 1334×750 pixels and 16overlapping raster lines. For comparison, the Galaxy S5 Android phonehas an 8 MP camera running at a shutter speed of 1/30 seconds. In otherembodiments, a decoding parameter database can be populated (offline)with the relevant parameters of currently available computing devices,and that database can be queried for decoding parameters associated witha given computing device (based on make and model). Alternatively, theuser of the given device 200 can be queried to manually enter variousdecoding parameters of interest (e.g., pixels, shutter speed, frameresolution, number of overlapping raster lines, and processor speed).

Once the decoding parameters are in hand, the method continues withcalculating 703 a baud rate suitable for the given computing device. Aswill be appreciated, using the receiving device 200 specifications, anoptimal baud can be rate computed so as to allow the device 200 toreceive LCom signals in some desired percentage of the frame, such as40% to 50%, or more. In more detail, assume a receiving device 200having a 4 MP camera running at a shutter speed of 1/60 second, as wellas a frame resolution and raster line timings of 1334×750 pixels and 16overlapping raster lines. Thus, the effective sampling rate can becomputed as follows: 750 raster lines per 1/60 second=45 k rasterlines/second. Now, further assume that it is desired to have 10 rasterlines per bit, which means initially that the baud rate should be 4.5kHz (=45 k/10).

With the baud rate calculated, the method continues with setting 705 thebaud rate at the luminaire. Continuing with the above example case,setting the baud rate would entail setting the luminaire baud rate to4.5 KHz or bps (bits per second). So, for example, this baud rate can beimplemented by the controller 150, which controls the on-off state ofthe light sources 110. In the case of multiple smart devices in the samearea, the baud rate can be set for the lowest common denominator (i.e.,the device 200 having the lowest baud rate), according to someembodiments. The luminaire can then start to transmit LCom signals atthat baud rate. For embodiments where the baud rate determination at 705is made external to the luminaire, the method may include, for example,passing the baud rate to the luminaire through a back channel such asBluetooth or WiFi (such as via network 300).

The method continues with measuring 707 and verifying the baud rate atthe receiving device 200. In some such embodiments, this can be done bymeasuring the luminaire length in raster lines. In more detail, andcontinuing with the above example where the LCom message is 32 bits longand there are 10 raster lines per bit, which means at least 320 rasterlines are needed to “see” the entire message at any one time in a single750 raster line frame. Further assume a shutter speed of 1/60 second,thereby providing 45 k raster lines per second. With these parameters inmind, note that the camera frame data of the computing device 200 can beused to measure the length of luminaire 100 in units of raster lines. Ifthe entire luminaire 100 covers more than 320 raster lines within agiven frame, then it follows that the entire LCom message (which covers320 raster lines) can be seen as well, within that given frame. As acorollary, if the entire luminaire 100 covers less than 320 raster lineswithin a given frame, then it further follows that the entire LCommessage (which needs 320 raster lines) cannot all be received or “seen”within that single frame.

For instance, in the example scenario shown in FIG. 8, T refers to thetotal number of raster lines making up one camera frame for device 200(assume T equals 750 raster lines, in the example case), and L refers tothe length (in raster lines) of the luminaire 100 being imaged in thecamera frame currently displayed (assume L equals 400 raster lines, inthis example case). Thus, the LCom message being broadcast by the imagedluminaire 100 can be captured in a single camera frame. However, if theimaged luminaire 100 was less than 320 raster lines, then the LCommessage being broadcast by the imaged luminaire 100 will not be completefor that baud rate. In this case, therefore, the baud rate could beincreased which sacrifices resolution to obtain the entire message or IDspread out over the luminaire. Thus, for instance, the 10 raster linesper bit can be changed to 5 raster lines per bit, thereby doubling thebaud rate from 4.5 Kbits/sec to 9 Kbits/sec. FIG. 9 shows a visual ofdifferent baud rates, including a relatively fast baud rate showing fourmessages within a given time period, and a relatively slow baud rateshowing two messages within that same given time period. Thus, the fastbaud rate is twice as fast as the slow baud rate. Because the fasterbaud rate is more compressed in time, it can be imaged with fewer rasterlines.

The method continues with adjusting 709 the receiving device parameters,if needed. In the case where the luminaire is either controlled by someother device or the baud rate is not settable, then the receiving deviceitself can try to adapt by changing its own timing with respect to, forexample, shutter speed and/or frame rate. To find the present baud rate,the receiver can observe the bit rate period and message length. Notethat in this case, the back channel is not needed to pass along the baudrate to the luminaire. In some embodiments, note that the receivingdevice can request changes in baud rate based on ambient conditions. Forexample, if a given receiving device includes a camera and a lightsensor, then ambient light conditions can be sensed and this informationcan be fed back to the luminaire to adjust baud rate to improve signalto noise ratio. For instance, in cases of high ambient light, theoptimal baud rate might be smaller to keep the desired signal to noiseratio. However, the ambient light might be a different waveform (andwavelength) such as IR. Thus, the amplitude and wavelength of ambientlight can be measured to assess same.

The method continues with determining at 711 whether or not the ID beingtransmitted by the luminaire is decodable at the given baud rate. Ifnot, then the process can repeat back to 703 in effort to determine abetter baud rate. On the other hand, if the ID being transmitted by theluminaire is decodable at the given baud rate, then the method continueswith decoding 713 LCom packets.

The method may further include monitoring 715 for changes of luminairein frame. For instance, in some embodiments, the appearance of theluminaires in the camera frame can be monitored, and the baud rate canbe adjusted based on this information. In one such embodiment, thereceiving device 200 periodically (e.g., every 3-30 frames) recalculatesthe optimal baud rate based on the visualization of the luminaires 100in the camera frame. In some cases, the receiving device 200 canoptionally try to adjust its own settings to optimize decoding or dealwith situations where luminaire control is not available for whateverreason. In still other scenarios, there may be a case where the neededbaud rate is too fast for the luminaire. One such example of this is thecase where the luminaire fills up only a small portion of the screen.For a linear light, this might just mean that the user should rotate thereceiving device 200 to better align the raster lines perpendicular tothe long dimension of the luminaire, as shown in FIG. 6A, for instance.In such cases, the user could be, for instance, prompted to rotate thereceiving device accordingly. In still other example embodiments, if theneeded baud rate is not available, then the user may be alerted (e.g.,generate and send alert message to display screen of receiving device200).

Thus, after iterating through the methodology as needed, the baud ratecan be set for reliable decoding regardless of any initial mismatch ofthe transmitting luminaire 100 and receiving device 200. As will beappreciated, the methodology allows for both adjusting the baud rate atthe transmitter side, and further allows the effective baud rate to bechanged using internal adjustments of the receiving device 200. Theseinternal adjustments may include changes to parameters such as camerashutter speed, camera resolution, camera frame rate, camera shuttermode, and signal gain (ISO), to name a few examples. For instance, acamera of a given receiver device 200 that is imaging the ceiling invideo mode might use a low ISO, fixed frame rate/shutter speed, andvideo resolution initially. If possible, the device 200 can be switched(manually by user or automatically by LCom-based navigation application216) from video mode to camera mode to utilize slower shutter speedsthan 1/30 seconds. This effectively increases the baud rate as now thesampling rate is slower. To compensate for the increased light with theslower shutter speed, the ISO can decrease. This example highlights twotypes of camera parameters that include: direct timing parameters, andlight compensation parameters that do not directly affect timing butcompensate for timing parameters for proper brightness. Timingparameters include: shutter speed, frame rate, resolution, and shuttermode. The compensation parameters include: ISO, aperture, and filters.Depending on the camera composition constraints and LCom-basedapplication 216 requirements, the timing parameters can be adjusted toeffectively change the baud rate from the point of view of the receivingdevice 200 while the compensation parameters adjust the light level backto optimal signal levels. Thus, adjustments to baud rate to not impactthe clarity of the imagery.

Numerous embodiments will be apparent in light of this disclosure. Oneexample embodiment provides a method for setting a baud rate forlight-based communication (LCom). The method includes: determiningdecoding parameters of a receiving device, the receiving deviceincluding a camera for receiving LCom signals, and a display;calculating a baud rate suitable for the receiving device based on thedecoding parameters; and causing the baud rate to be set at anLCom-enabled luminaire. In some cases, the method is carried out atleast in part on the receiving device. In some cases, the receivingdevice being a mobile computing device. In one such case, the receivingdevice is a smartphone or tablet computer. In some cases, the decodingparameters include at least one of shutter speed of the camera, frameresolution of the camera, and orientation of the luminaire with respectto a raster direction of the camera. In some cases, determining decodingparameters of a receiving device includes at least one of: querying adatabase of known receiving devices to identify relevant decodingparameters; and accessing a local storage of the receiving device toidentify relevant decoding parameters. In some cases, causing the baudrate to be set at an LCom-enabled luminaire comprises passing the baudrate to the luminaire via a radio frequency wireless communicationchannel. In some cases, the method further includes measuring andverifying the baud rate at the receiving device. In some cases, themethod further includes adjusting the decoding parameters of thereceiving device if baud rate cannot be adjusted to meet a currentconfiguration of decoding parameters. In some cases, the method furtherincludes: determining whether or not an ID being transmitted by theluminaire is decodable at the baud rate; and in response to the ID beingdecodable at the given baud rate, continuing to decode LCom signals atthe baud rate; and in response to the ID not being decodable at thegiven baud rate, calculating a different baud rate. In some cases, themethod further includes: monitoring for changes of luminaire in frame;and prompting a user to rotate the receiving device to improveorientation of the luminaire with respect to a raster direction of thecamera. Another embodiment provides a non-transitory computer readablemedium encoded with instructions that, when executed by one or moreprocessors, causes a process for setting a baud rate for light-basedcommunication (LCom) to be carried out, the process including themethodology as variously described in this paragraph. The non-transitorycomputer readable medium may include, for example, one or more machinereadable mediums, such as a hard disk, ROM, solid state drive, thumbdrive, embedded controller memory, compact disc, server computer, orother such non-transitory mediums that can be accessed by one or moreprocessors so that the instructions thereon can be executed to carry outthe process. Note that the process so encoded on the computer readablemedium need not be carried out, and may remain unexecuted in some suchembodiments.

The foregoing description of example embodiments has been presented forthe purposes of illustration and description. It is not intended to beexhaustive or to limit the present disclosure to the precise formsdisclosed. Many modifications and variations are possible in light ofthis disclosure. It is intended that the scope of the present disclosurebe limited not by this detailed description, but rather by the claimsappended hereto. Future-filed applications claiming priority to thisapplication may claim the disclosed subject matter in a different mannerand generally may include any set of one or more limitations asvariously disclosed or otherwise demonstrated herein.

What is claimed is:
 1. A method for setting a baud rate for light-basedcommunication (LCom), the method comprising: determining decodingparameters of a receiving device, the receiving device including acamera for receiving LCom signals, and a display; calculating a baudrate suitable for the receiving device based on the decoding parameters;and causing the baud rate to be set at an LCom-enabled luminaire.
 2. Themethod of claim 1, wherein the method is carried out at least in part onthe receiving device.
 3. The method of claim 1, wherein the receivingdevice being a mobile computing device.
 4. The method of claim 3,wherein the receiving device is a smartphone or tablet computer.
 5. Themethod of claim 1, wherein the decoding parameters include at least oneof shutter speed of the camera, frame resolution of the camera, andorientation of the luminaire with respect to a raster direction of thecamera.
 6. The method of claim 1, wherein determining decodingparameters of a receiving device includes at least one of: querying adatabase of known receiving devices to identify relevant decodingparameters; and accessing a local storage of the receiving device toidentify relevant decoding parameters.
 7. The method of claim 1, whereincausing the baud rate to be set at an LCom-enabled luminaire comprisespassing the baud rate to the luminaire via a radio frequency wirelesscommunication channel.
 8. The method of claim 1, further comprising:measuring and verifying the baud rate at the receiving device.
 9. Themethod of claim 1, further comprising: adjusting the decoding parametersof the receiving device if baud rate cannot be adjusted to meet acurrent configuration of decoding parameters.
 10. The method of claim 1,further comprising: determining whether or not an ID being transmittedby the luminaire is decodable at the baud rate; and in response to theID being decodable at the given baud rate, continuing to decode LComsignals at the baud rate; and in response to the ID not being decodableat the given baud rate, calculating a different baud rate.
 11. Themethod of claim 1, further comprising: monitoring for changes ofluminaire in frame; and prompting a user to rotate the receiving deviceto improve orientation of the luminaire with respect to a rasterdirection of the camera.
 12. A non-transitory computer readable mediumencoded with instructions that, when executed by one or more processors,causes a process to be carried out for setting a baud rate forlight-based communication (LCom), the process comprising: determiningdecoding parameters of a receiving device, the receiving deviceincluding a camera for receiving LCom signals, and a display;calculating a baud rate suitable for the receiving device based on thedecoding parameters; and causing the baud rate to be set at anLCom-enabled luminaire.
 13. The computer readable medium of claim 12,wherein the process is carried out at least in part on the receivingdevice, and the computer readable medium and one or more processors areincluded in the receiving device, the receiving device being a mobilecomputing device.
 14. The computer readable medium of claim 12, whereinthe decoding parameters include at least one of shutter speed of thecamera, frame resolution of the camera, and orientation of the luminairewith respect to a raster direction of the camera.
 15. The computerreadable medium of claim 12, wherein determining decoding parameters ofa receiving device includes at least one of: querying a database ofknown receiving devices to identify relevant decoding parameters; andaccessing a local storage of the receiving device to identify relevantdecoding parameters.
 16. The computer readable medium of claim 12,wherein causing the baud rate to be set at an LCom-enabled luminairecomprises passing the baud rate to the luminaire via a radio frequencywireless communication channel.
 17. The computer readable medium ofclaim 12, the process further comprising: measuring and verifying thebaud rate at the receiving device.
 18. The computer readable medium ofclaim 12, the process further comprising: adjusting the decodingparameters of the receiving device if baud rate cannot be adjusted tomeet a current configuration of decoding parameters.
 19. The computerreadable medium of claim 12, the process further comprising: determiningwhether or not an ID being transmitted by the luminaire is decodable atthe baud rate; and in response to the ID being decodable at the givenbaud rate, continuing to decode LCom signals at the baud rate; and inresponse to the ID not being decodable at the given baud rate,calculating a different baud rate.
 20. The computer readable medium ofclaim 12, further comprising: monitoring for changes of luminaire inframe; and prompting a user to rotate the receiving device to improveorientation of the luminaire with respect to a raster direction of thecamera.